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1. SIGNALLING CONNECTION CONTROL PART MESSAGES 


The signalling connection control part (SCCP) messages are used by the peer-to-peer protocol. The 
meaning and definition of the various information elements contained in these messages are specified in 
Section 2. The actual inclusion of these information elements in a given message depends on the class of 


protocol and is specified in Section 3. 


1.1 Connection-oriented protocol classes (2, 3, 4). [Text from the CCITT Red Book Vol. VI 
pertaining to connection-oriented messages and procedures has been temporarily removed. ] 


1.1.1 Connection establishment phase. 
1.1.1.1 Connection request (CR). 

~ 1.1.1.2 Connection confirm (CC). 
1.1.1.3 Connection refused (CREF). 
1.1.2 Connection release phase. 
1.1.2.1 Released (RLSD). 

1.1.2.2 Release complete (RLC). 
1.1.3 Data transfer phase. 

1.1.3.1 Data form 1 (DT}). 

1.1.3.2 Data form 2 (DT2). 

1.1.3.3 Data acknowledgement (AK). 
1.1.3.4 Expedited data (ED). 


1.1.3.5 Expedited data acknowledgement (EA). 


1.1.3.6 Reset request message (RSRM). 
1.1.3.7 Reset confirmation message (RSCM). 
1.1.3.8 Protocol data unit error (ERR). 
1.1.3.9 Reject (RJ). 

1.1.3.10 Restart request (RTR). 

1.1.3.11 Restart confirmation (RTC). 
1.1.3.12 Inactivity test (IT). 


1.2 Messages for connectionless protocol classes (0 and 1). 


1.2.1 Unitdata (UDT). A SCCP wanting to send data in a connectionless mode uses a “unitdata" message. 


A "“unitdata” message must contain the called party address parameter, the calling party address 
parameter (which may not include any information), the protocol class and user data. 


An asterisk ‘'*’ indicates a change from the CCITT Red Book Vol VI that is specific to U. S. Networks 
A bar |’ indicates a change from Issue | of Bell Communications Research Specification of Signalling System Number 7, Vol. | and 
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1.2.2 Unitdata service (UDTS). 


Whenever it is not possible to route a “unitdata” message and the message return on error option is 
included, a “unitdata service" message is sent back to the originator. | 


A “unitdata service” message contains the following information: the called party address parameter, 
the calling party address parameter (which may not include any information), the diagnostic and the 
returned user data. 


1.3 Messages for SCCP sub-system management. 


1.3.1 Subsystem-Prohibited. The Subsystem-Prohibited (SSP). message is sent to concerned destinations to— 


inform SCCP Management (SCMG) at the destinations of the failure of a subsystem. Upon receipt of a 
SSP message, the SCCP routing tables are updated. 


A: SSP message must contain the following information: the prohibited subsystem, the point code of 
the prohibited subsystem, and the Subsystem Multiplicity Indicator (SMD). 


1.3.2 Subsystem-Allowed. The Subsystem-Allowed (SSA) message is sent to concerned destinations to 
inform SCMG at the destinations that a subsystem which was formerly prohibited is now allowed. Upon 
receipt of a SSA message, the SCCP routing tables are updated. 


A SSA message must contain the following information: the allowed subsystem, the point code of the 
allowed subsystem, and the Subsystem Multiplicity Indicator. 


1.3.3 Subsystem-Status-Test. SCMG at a node which has received a SSP message starts an audit 
procedure. The purpose of this procedure is to provide a mechanism for recovery in the event ena a SSA 
message is lost. 


A Subsystem-Status-Test message must contain the following information: the subsystem being 
audited, the point code of the subsystem being audited, and the Subsystem Multiplicity Indicator. 


1.3.4 Subsystem-Out-of-Service-Request. When a subsystem wishes to go out-of-service, the request is 
transferred by means of a Subsystem-Out-of-Service-Request (SOR) message between the SCMG function 
at that node and the SCMG at the duplicate subsystem’s node. The purpose of the SOR message is to allow 
subsystems to go out-of-service without degrading performance of the network. 


A SOR message must contain the following information: the affected subsystem, the point code of the 
subsystem, and the Subsystem Multiplicity Indicator. 


1.3.5 Subsystem-Out-of-Service-Grant. When SCMG receives a SOR message, if both it and the concerned 
subsystem agree to the request, a Subsystem-Out-of-Service-Grant (SOG) message is sent to the SCMG 
function associated with the duplicate subsystem. 


The SOG message must contain the following information: the affected subsystem, the point code of 
the subsystem, and the Subsystem Multiplicity Indicator. , 


1.3.6 Subsystem-Backup-Routing (Architecture Dependent). If a subsystem becomes prohibited at an end 
node adjacent to an intermediate node, a Subsystem-Backup-Routing (SBR) message is sent by SCMG at 
the intermediate node to SCMG associated with the backup subsystem. The SBR message is sent prior to 
rerouting traffic to the backup subsystem. The purpose of the SBR message is to provide additional network 
connectivity information so that SCMG at the end node may determine the traffic mix received for a 
subsystem. | 


The SBR message must contain the following information: the affected subsystem, the point code of 
the subsystem, and the Subsystem Multiplicity Indicator. 


1.3.7 Subsystem-Normal-Routing (Architecture Dependent). If a subsystem that was prohibited becomes 
allowed at an end node adjacent to an intermediate node, a Subsystem-Normal-Routing (SNR) message is 
sent by SCMG at the intermediate node to SCMG associated with the backup subsystem. The SNR 
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message is sent, pricr to rerouting traffic to the primary subsystem, to the backup of the now allowed 
subsystem. This allows SCMG at the end node to Papeete the traffic mix information that the subsystem is 


receiving. 


The SNR message must contain the following information: the affected subsystem, the point code of 
the subsystem, and the Subsystem Multiplicity Indicator. 


1.3.8 Subsystem-Routing-Status-Test (Architecture Dependent). SCMG at a node that received a SBR 
message, sends a Subsystem-Routing-Status-Test (SRT) message periodically to SCMG at the node that 
originated the SBR message. The purpose of this procedure is to provide a mechanism for recovery from a 


lost SNR message. 


The SRT message must contain the following information: the affected subsystem, the point code of 
the subsystem, and the Subsystem Multiplicity Indicator. 


2. MESSAGE FIELDS 


2.1 Message type code. The "message type code” field is to be found in all the messages. It uniquely 
identifies the type of the messages (CR, CC... as described in Section 1). 


2.2 Local reference number (source/destination). [This field is only used for connection-oriented 
procedures. | 


a Calling/ called party address. The "calling/called party address” field contains enough information 
to uniquely identify the origination/destination signalling point and/or the SCCP access point. 


[t can be any combination of a global title (dialed digits for example). a signalling point code, and a 
subsystem number. In order to allow the interpretation of this address, it begins with an address indicator 
which indicates which information elements are present. 


The address indicator also includes a routing indicator specifying if translation is required, a global 
title indicator specifying global title format, and a national/international indicator specifying use of national 
or international coding methods. 


The addition of the ISDN Call Identity as a separate element or as part of the above mentioned 
elements (e.g., the global title) is a subject for further study. 


The "calling/called party address" parameter has two different meanings depending on whether it is 
included in a connection-oriented or connectionless message. 


For a connection-oriented message these fields have a global significance (i.e. independent of the 
direction the message is going). 


For a connectionless message these fields have a local significance (i.e. dependent on the direction the 
message is going just as for OPC and DPC). 


2.4 Protocol class. For connection-oriented protocol classes, the "protocol class” field is used during the 
connection establishment phase: it is negotiated between the two-end SCCPs. 


For connectionless protocol classes the “protocol class" field is used also to indicate whether or not a 
message should be returned on error occurrence. . | 


2.5 Segmenting/reassembling. [This field is only used for connection-oriented procedures.] 
2.6 Receive sequence number. [This field is only used for connection-oriented procedures.] 
2.7 Sequencing/segmenting. [This field is only used for connection-oriented procedures. ] 


2.8 Credit. [This field is only used for connection-oriented procedures.] 
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2.9 Refusal cause. 
[This field is only used for connection-oriented procedures. ] 
2.10 Release cause. [This field is only used for connection-oriented procedures.] 


2.11 Diagnostic. For connectionless protocol classes the “diagnostic” field is used to indicate the reason 
why a message was returned. 


For connection oriented protocol classes the “diagnostic” field is for further study. 
2.12 Reset cause. [This field is only used for connection-oriented procedures. ] 
2.13 Error cause. [This field is only used for connection-oriented procedures.] 


2.14 User data. The “user data” field contains information coming from upper layers or from SCCP 
management. 


2.14A Affected subsystem number 


The "affected subsystem number (SSN)" identifies a subsystem which is failed, withdrawn, 
congested, or allowed. In the case of SST or SRT message, it also identifies the subsystem being audited. 
In the case of SOR or SOG message, it identifies a subsystem requesting to go out of service. 


2.14B Affected point code 
The “affected point code (PC)" identifies a point code where the affected subsystem is located. 
2.14C Sub-system multiplicity indicator « 


The "sub-system multiplicity indicator” is used in "SCCP management messages” to indicate the 
number of associated replicated subsystems. 


2.15 End of optional parameters. The "end of optional parameters” field is used in any message 
containing optional parameters to indicate where the part allocated to these optional parameters ends. 


3. INCLUSION OF FIELDS IN THE MESSAGES 


The inclusion of the information elements specified in Section 2 in the various messages specified in 
Section 1 according to their type depends on the class of protocol. SCCP messages are specified in Table 
1/Q.712 and SCCP management messages are specified in Table 2/Q.712. 


The following applies to Tables 1 and 2/Q.712: 
MAN = mandatory field 


OPT = optional field (which is included in a message when needed) 


Note I: For further study 
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Message: | cree RLSO | ALC {| OT1 | OT2 | AK RSCM iT UOT } UDTS RTR | ATC 
Fields m) (1) 7 () 
Destination local 
reference number 
Source local 


Called party address MAN | OPT | OPT || MAN 


ener tere rerrter ty 
=a ec 
1 
ee PPP ee 
eee 
=e 


Release cause | | | MAN | : | | | | | 


Diagnosuc{1) OPT OPT 


MAN 
= 
ee CC ee 
= eee ee 
== eC 
mee lel EEL 


TABLE 1/Q.712. Inclusion of Fields in Messages 
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Messages | SSP/SSA/|SST {SOR |SOG|SBR{SNR/SRT | 
Fields ; | | | 


Affected SSN MANIMANIMANIMANIMANIMANIMAN|MAN 


Sub-system 
multiplicity indicator MAN|MANIMAN MANIMAN|MANI] MANIMAN 


TABLE 2/Q.712. SCCP Management Messages 
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Sub-system 
ee Ate a ey mimimimimit mi mim 
multiplicity indicator 


TABLE 2/Q.712 -Subsvstem Management Messages. 
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